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Provision for the functional testing of fabricated VLSI 
chips frequently involves as much design effort as the orig- 
inal chip design itself. Often the hardware requirements for 
testing involve a large expense. 

This research investigates the logical and functional 
requirements for chip testing. Available approaches are 
examined and their capabilities noted. Methods of communica- 
tion between the test controller and the device under test 
are examined as well as logical structure of the test 
controller. 

Two candidate approaches are selected for comparison. 
(1) A standard general-purpose processor with standard bus 
interface serves as the test controller and (2) a custom 
VLSI test controller interfacing directly to the device 
under test. As a result, a test system architecture is 
proposed. 
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I. INTRODUCTION 



The continued and rapid increase in the performance and 
complexity of VLSI technology creates a challenge for the 
design, development and test of integrated circuits. 

This motivation attracts attention to the structured 
design methods which make possible the implementation of 
VLSI systems with little previous experience. There are 
design validation tools available, e. g. , layout languages, 
design rule checkers, circuit extractors and simulators. 
These tools provide a simple way to simulate and verify the 
design. On the other hand, designers have no widespread and 
easy to use tools for debugging and testing when they 
receive their chip. If prototype chips are to be used in 
systems it is essential to verify that the designed chip 
performs the intended function successfully. So the problem 
of developing a methodology to test the circuits of VLSI 
technology efficiently needs to be addressed. 

Properly defined test vectors are applied to the inputs 
of the device under test and outputs can be compared to a 
stored correct response. The simplest testing idea is shown 
in Figure 1.1 . In general, 2 n test vectors are required in 
this case. 
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/ ^ 
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Incuts 

(Test vectors) 


Outputs 
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Figure 1. 1 Combinational Circuit. 
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The test vectors should be carefully selected if they 
are to supply relevant information about a chip [Ref. 1]. A 
sequential circuit, as in Figure 1.2, is more difficult to 
test, since the output of a sequential circuit network 
depends not only on the present inputs but also on the 
internal state of the circuit. The number of test vectors 
required for this case are 2 ri " l ’ rn . 
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Figure 1. 2 Sequential Circuit. 



It is a fact that that test vectors may be generated and 
results may be compared in a computer aided environment. 

The rest of the chapters investigate testing methods and 
systems for integrated circuit chips. In Chapter Two the 
most popular and available approaches are examined. Their 
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advantages and disadvantages are noted. The main purpose of 
this study is to set basic guidelines and decide on a useful 
test strategy for an academic environment. Chapter Three 
introduces the requirement of testing and explains why a 
functional test strategy is chosen. In Chapter Four, two 
candidate approaches for a tester are examined and results 
are derived. The first one is a general purpose processor 
with standard bus interface and serves as the test 
controller. The second is a custom VLSI test controller 
interfacing directly to the device under test. Chapter Five 
proposes a test system architecture which includes all of 
the considerations derived before. Conclusions and 
recommendations are given in the last chapter. 
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II. CONCEPT OF TESTING VLSI CIRCUIT CHIPS 



A. DESIGN VERIFICATION 

Design Verification is a test process which is done 
during the design. Following are two definitions of Design 
Verification: 



1. " Design Verification Testing involves the simulation 
of a set of input nodes with a known set of input test 
vectors and capture of vectors from a set of output 
nodes to verify the logical integrity of a design. 
[Ref. 2 ] 

2. " Design Verification (is the process of) estab- 
lishing that the logical design of a given digital 
network does not contain any timing problems which 
could prevent it from performing the intended func- 
tion under certain conditions. [Ref. 3] 



Design Verification is performed to ensure that all 
circuit characteristics are compatible, that required speci- 
fications can be achieved, and to ensure that no major 
design flaws remain. Simulation is employed to check for the 
adequacy of the design. In general this may be accomplished 
with assistance from a design automation system [ Ref. 4] . 
It must be noticed that verification techniques and tools 
are used during the design phase. The test capability we 
wish to develop, which is different than design verifica- 
tion testing, is to verify that the designed chip 
accomplishes its intended function successfully. 



B. TEST GENERATION AND VERIFICATION 

Test generation is the process of searching for a 
sequence of input test vectors which verify correct behavior 
of the circuit. Test verification is concerned with finding 
measures of effectiveness of a given set of test vectors. 
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Test generation is complicated by flip-flops, circuit 
initialization needs, asynchronous circuits, indeterminate 
states and non-functional inputs [Ref. 5]. On the other 
hand, a complete set of test vectors does not guarantee an 
adequate test. All of these considerations should be 
addressed when developing a test strategy and a test plan. 

As stated in [Ref. 6], test generation must consist of 
three main activities: 



1. Selecting a good descriptive model, at a suitable 
level, for the system under consideration. Such a 
model should reflect the exact behavior of the system 
in all its possible modes of operation. 

2. Developing a fault model to define the types of faults 
that will be considered during test generation. In 
selecting a fault model, the percentage of possible 
faults covered by the model should be maximized, and 
the test costs associated with the use of the model 
should be minimized. A good fault model is usually 
found as a result of a trade-off between them. 

3. Generating tests to detect all the faults in the fault 
model. This part of test generation is the essential 
piece of the whole test process. Generating a test 
sequence to detect a certain fault in a digital, 
circuit usually involves two problems. First, the 
fault must be excited; i.e, a certain test sequence 
must be applied that will force a faulty value to 
appear at the fault location if the fault exists. 
Second, the test must be made sensitive to the fault; 
i.e., the effect of the fault must propagate through 
the network to an observable output. 



It is also important to locate the fault as well as 
detecting it. The test strategy is going to be changed, 
depending on whether it is desired simply to detect the 
fault or both to detect and locate the fault. 

The challenge of fault simulation and test verification 
problems has received a lot of attention, and the task of 
test generation has been partially overlooked. The use of a 
random-number pattern generator and generation of a test 
which detects a single failure shows the degree of underes- 
timation of the importance of the test-generation process. 
The manual generation of test patterns is a difficult, time- 
consuming job even for moderate size circuits. The task of 
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fault simulation and test verification is a bookkeeping, 
grading, direction-giving, and fault-dictionary-building 
task. [ Ref. 7] 

Fault simulation has been the goal of test generation, 
yielding a quantitative measure of test effectiveness. In 
other words, a test sequence is considered good if it can 
detect a high percentage of the possible device under test 
faults. It goes beyond logic and timing verification and is 
a more complex process. Fault simulation must predict how a 
circuit will, or can, fail and if this failure happens, the 
test program must be comprehensive enough to find it. 
[Ref. 5] 

There are lots of algorithms, models and simulations 
based on fault detection. Let us review them briefly. 

1. Fault Simulation and Fault Models 

Extensive studies have been made of the failures 
occurring in integrated circuits. These are examined in 
[Ref. 9]. This report states that failures have two major 
sources: defects in the manufacturing process, and component 

wearout. The frequency of occurrence and relative importance 
of the various faults depends on the circuit type (TTL, ECL, 
NMOS, CMOS, etc. ) and the manufacturing technology used. 
Table 1 from [Ref. 9] summarizes the most common IC faults. 

Given any physical fault mechanism in a circuit, it 
is possible, at least in principle, to determine its effect 
on the logical behavior of the circuit. As stated in [ Ref. 
9] , there are several advantages to using logical fault 
models instead of physical fault models: 

1. Once we have a logical fault model that adequately 
reflects the physical failure modes of a circuit, 
fault analysis becomes a logical rather than a phys- 
ical problem. 

2. It is possible to construct logical fault models 
that are applicable to many different technologies, 
in which case fault analysis becomes relatively 
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TABLE 1 

REPRESENTATIVE PHYSICAL FAILURES IN ICS 

Package wiring faults 

On-chip metalization ( aluminum) faults due to: 
Corrosion 
Electromigration 
Microcracks 
Bridging 

Dielectric ( silicon dioxide) faults due to: 
Mask defects 
Electrostatic discharge 

Surface faults 

Threshold shifts 

Pattern sensitivity 

Soft faults due to: 

Alpha particles 
Cosmic rays 



technology- independent. This means that computer 
programs ror fault simulation and test generation 
can be written that do not lose their usefulness with 
changes in technology. 

3. Using logical fault models it may be possible to 
derive tests for faults whose physical reason is 
unknown, or whose effect on circuit behavior is not 
completely understood. 
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4. A logical fault model often covers a large number of 
different physical faults, resulting in a substantial 
decrease in the complexity of fault analysis. 



Various criteria may be used for classifying both 
physical and logical faults; Table 2 lists the most 
important ones [Ref. 9]. 



TABLE 2 

PARAMETERS FOR CLASSIFYING FAULTS IN DIGITAL SYSTEMS 

Variability with respect to time: 

Permanent 

Intermittent 

Transient 

Number of primitive faults that may be 
present simultaneously: 

Single faults 
Multiple faults 

Effect on components 

Effect on interconnections between components 
Effect on operating speed 



Most of the studies have addressed the single stuck 
fault. A commonly used fault model is the Stuck-At model. A 
faulty gate input in a circuit is modeled as a Stuck-At-0 
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( S-A-0 ) or a Stuck-At-1 (S-A-l). When a certain number of 
input test vectors are applied to a circuit, the percentage 
fault coverage depends on the number of S-A-0 or S-A-l 
faults that can be detected by the input test sequence as a 
percentage of the total number of single faults that might 
happen. Some other fault types are: multiple stuck-at 

faults, delay faults, pattern sensitive faults and 
short-circuit faults. 

2. Stuck-At Model 

This model does not take into account all possible 
defects, but is a more global type of model. It assumes that 
a logical gate input or output is fixed to either a logic 0 
or a logic 1. For example, the faulty AND gate pictured in 
Figure 2.1 (b) perceives the A input as 1, even if the logic 
value 0 is placed on the input. 

The pattern applied to the fault free AND gate in 
Figure 2.1 (a) has an output value of 0 since the input is 0 
on the A input and 1 on the B input. But the pattern in 
Figure 2.1 (b) shows an output of 1, since the A input is 
perceived as a 1 even though a 0 is applied to that input. 
Therefore, the pattern shown in Figure 2.1 is a test for' 
the A input, S-A-l, because the good machine 
responds differently from the faulty machine. [ Ref. 8] 

Techniques are available to decrease the complexity 
of fault simulation, however, it is still a time consuming 
and expensive task. It has been observed in [Ref. 8] that 

the computer run time to do test generation and fault simu- 
lation is approximately proportional to the number of logic 
gates to the power of 3. 

The problem with CMOS is that there are a number of 
faults which could change a combinational network into a 
sequential network. Therefore, the combinational patterns 
are no longer effective in testing the circuit in all cases. 
[Ref. 10,11] 
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Figure 2. 1 Test for input stuck at fault. 

It was noted previously that single stuck-at fault 
test sets seem to provide acceptable levels . of fault 
coverage for devices fabricated with current technology. 
Advances in VLSI technology are rapidly changing circuit 
characteristics, however, and it would be desirable to 
anticipate the effect of these changes on the occurence of 
multiple faults. During the fabrication process a single 
surface defect or a variation in processing parameters can 
cause multiple faults. The major problem in developing test 
sets for multiple fault detection is the large number of 
possible faults. For example, it is calculated in [Ref. 12] 
that if we have a circuit with only 10 nodes there are 20 
single stuck-at faults, 180 double faults, 960 triple 
faults, and 59048 possible stuck-at fault patterns. For 
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today's VLSI circuits, which may contain in excess of 100000 
nodes, it can be easily seen that explicit test generation 
for anything other than single faults is impractical. 

In summary, fault simulation has some difficulties 
in VLSI circuit applications. The increase in circuit 
complexity makes the simulation of all gate-level faults 
very time consuming. The gate level description of the VLSI 
chip must be available and good documentation is required. 
Consideration of only single stuck-at faults may be inade- 
quate. Multiple faults, non-stuck type faults and suspended 
temporarily at intervals type faults are important 
but either difficult or impractical to process. [ Ref. 
9,11,12,13,14, 15,16] 

3 . D Algorithm 

The D-algorithm is a method for generating a test 
vector for a given fault. This algorithm, developed by Roth 
at IBM, is probably the most widely used test generation 
procedure [Ref. 17]. It is typically used with gate-level 
circuit models and stuck faults. The D-algorithm attempts to 
construct a sensitized path over which an error signal can 
propagate from the fault location to an observable primary 
output line. It systematically assigns values to lines asso- 
ciated with each potential sensitized path until a valid 
assignment is found, if one exists. Using a backtracking 
approach based on the circuit structure, the D-algorithm 
searches the space of possible test patterns for the given 
fault. The method in its most general form can always find a 
test or, in the case of an undetectable fault, prove that no 
test pattern exists for it. [Ref. 9,17,18] 

It is worth noting that the D-algorithm is particu- 
larly well-suited to test generation for circuits designed 
using LSSD (Level Sensitive Scan Design) and similar tech- 
niques. A large number of practical test generation programs 
and algorithms are based on the D-algorithm. [Ref. 9] 
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With the vast increase in circuit density, the 
ability to generate test patterns automatically and conduct 
fault simulation with these patterns has decreased. As a 
result, some manufacturers are skipping these more difficult 
approaches and are accepting the risks of shipping a defec- 
tive product. One general approach to reduce the cost of 
testing is embodied in a collection techniques known as 
Design for Testability. [Ref. 8] 



C. DESIGN FOR TESTABILITY 

Design for testability is motivated by the need to 
reduce the costs associated with testing and maintaining a 
digital system over its working life. Major testability 
considerations include test generation difficulty, test 
sequence length, test application cost, fault coverage and 
fault resolution. The costs are basically those of the 
computer time required to run test pattern, personnel to 
write the test pattern programs and test equipment [ Ref. 9] . 
The objective is to design circuits from the outset so 
that test verification and test generation efforts are 
limited in magnitude [ Ref. 10] . 

Testability relies on designer awareness of two concepts 
called controllability and observability. Controllability is 
the ability to set and reset every node internal to the 
circuit. Observability is the ability to observe either 
directly or indirectly the state of any node in the circuit. 
There are programs that can compute controllability and 
observability for a given circuit [Ref. 19,20]. 

Three basic approaches to design for testability are ad 
hoc testing, a structured design approach, and self-test and 
built-in testing. 
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1. Ad Hoc Testing 



Common techniques involve partitioning large 
sequential circuits and adding test points, but are not 
directed at solving the general sequential problem. The use 
of test and control points which attempt to improve local 
observability and controllability is basic guideline. Ad 
hoc techniques usually offer relief, and their cost is prob- 
ably lower than the cost of the structured approaches. The 
ad hoc approaches use partitioning, test points, bus- 
structured design and signature analysis. [Ref. 8, 10] 

2. Structured Design for Testability 

With the utilization of LSI and VLSI technology, it 
has become apparent that even more care has to be taken in 
the design stage in order to ensure testability and produce- 
ability of digital circuits. Most structured design prac- 
tices are built upon the concept that if the values in all 
the latches can be controlled to any specific value and 
observed with a very straightforward operation, then the 
test generation, and possibly the fault task, can be reduced 
to that of doing test generation and fault simulation for a 
combinational logic network. It is stated in [Ref. 8] that 
several companies have been dedicating significant amounts 
of resources toward Structured Design for Testability. They 
have recognized that unstructured designs lead to 
unacceptable testing problems. 

The most common techniques under structured design 
concept are: LSSD ( Level-Sensitive Scan Design) , Scan Path, 
Scan-set Logic Structures and Random Access Scan techniques 
[Ref. 8,9,21,22]. We only review the most popular 
approach -- IBM's LSSD discipline. 
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a. Level Sensitive Scan Design 

With LSSD, the only type of storage element 
(other than arrays) permitted in a logic design is the SRL 
(shift register latch). Figure 2.2 from [Ref. 22] shows a 
typical SRL configuration. An SRL is a pair of polarity hold 
latches with the output of the first latch, LI, permanently 
connected to the data input of the second latch, L2. AIs 
represent and-invert gates and Ns represent nor gates. 
[Ref. 8,22) 



LI 



i 1 







Figure 2.2 Shift Register Latch. 



The LI latch can be set either by the system 
data/clock or by the scan data/A clock because it functions 
as a storage element during system operation and as a compo- 
nent of the LSSD shift register during testing. All the SRLs 
on a chip are connected into a shift register with the input 
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to the first SRL designated Scan Data In and the output of 
the last SRL L2 latch designated Scan Data Out. In Figure 
2.3 from [Ref. 22] the dashed line represents the shift 
path. Two chip inputs for the non-overlaping scan A and B 
clocks are connected in common to the SRLs LI and L2. The 
designer has lost the use of four chip pins and the circuits 
required to implement the L2 latch and associated clock 
drivers, but the connection of the SRLs into a shift 
register in no way interferes with the normal functional 
operation of the chip. The four pins and the L2 latches 
enable the test system to control and retrieve the contents 
of any storage element on the chip by a simple shift 
technique. 




Figure 2. 3 Typical LSSD Chip. 
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The only requirement during shifting is that all 
functional system clocks remain inactive so as not to inter- 
fere with the shift operation. In addition, all functional 
system clocks must be controllable at the inputs to the 
chip. These system clocks are Cl and C2 in Figure 2. 3 . 

The LSSD technique reduces the testing problem 
to one of generating tests for combinational logic. Test 
patterns are generated automatically with the assumption 
that each SRL is a pseudo primary input/pseudo primary 
output, and access to these inputs and outputs can be gained 
by shifting into or out of the shift register. These gener- 
ated test patterns are scanned into the SRLs to simulate the 
combinatorial logic internal to the chip. Primary input 
stimuli are applied and system clock inputs are pulsed to 
capture the resulting state of the combinatorial logic. The 
shift register is than scanned out and examined for' expected 
results which are obtained by simulation. In this manner the 
chip is tested for typically 98-100% of all DC stuck faults 
with program generated test data. [Ref. 22] 

The cost of LSSD, on first look, is a signifi- 
cant overhead in unusable circuits. The L2 latch, the extra 
clock drivers (for the shift clocks), and the extra scan 
data input to the LI all constitute circuits which must 
exist for testing, but are not available to the designer for 
his unrestricted use in implementing the processor function. 
These circuits represent the hardware cost of LSSD and can 
often approach 20% of the available circuits. [Ref. 22] 

A typical application of the LSSD technique can 
be seen on the PLA cell design in Mathews and Newkirk' s VLSI 
Designer's Library. [Ref. 23] 

3. Built- in Test And Self- test 

One approach to built-in test is known as BILBO 
(Built-In Logic Block Observation). It takes the Scan Path 



25 



and LSSD concept and integrates it with the Signature 
Analysis concept [Ref. 24]. A 3-bit register is shown in 
Figure 2. 4 from [ Ref. 10] with the associated circuitry. In 
mode A (00=0, =1)/ the registers act as conventional 

parallel registers. The a^ values are loaded into the L' c 
, and the outputs are available on Q * . In mode B ( C 0 = C, 

= 0), the registers act as scan registers. In mode C ( C 0 = 
1, C., = 0), the registers act as a signature analyzer or 

pseudo-random sequence generator (PRSG). The registers are 
reset if C 0 = 0 and = 1. Thus a complete test generation 
and observation arrangement can be implemented as shown in 
Figure 2. 5 , [ Ref. 10] . The BILBO register on the left is 

used as the pseudo-random sequence generator. Its outputs 
are applied to the combinational circuitry. The combina- 

tional circuitry response are stored in the BILBO register 
on the right which is used as a signature analyzer. After a 
certain number of patterns have been applied, the signature 
is scanned out of the BILBO register and compared against 
the actual data. [Ref. 8,10] 

In LSSD or other structured design techniques, a 
considerable amount of test data volume is involved with the 
shifting in and out. With BILBO, if 100 patterns are run 
between scan-outs, the test data volume may be reduced by 
factor of 100. The overhead for this technique is higher 
than for LSSD since about two EXCLUSIVE-OR 1 s must be used 
per latch position. Also, there is more delay in the system 
data path. 

Other techniques that are going to be introduced 
very briefly, are Syndrome Testing and Autonomous Testing. 
In syndrome testing, which requires exhaustive testing, all 
possible inputs are applied to the circuit and the number of 
l's at the output are counted. The resultant value is 
compared with that of a known good machine. Extra circuitry 
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Figure 2.4 BILBO Usage. 




Figure 2. 5 BILBO Circuitry. 

includes a pattern generator, a counter, and a comparison 
circuit. [Ref. 8,10,25,26] 

On the other hand, in the autonomous test approach, 
modules are partitioned into small modules, which are then 
tested exhaustively. [Ref. 8,10,15] 
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D. 



SIGNATURE ANALYSIS 



Compact testing methods attempt to solve the problem of 
analyzing and storing the large amount of response data 
which is required for a good response generation. It is 
possible to compact response data R into a form f(R) which 
includes most of the fault information. This eliminates the 
need for a large memory and additional circuit units. 

A general form of a signature of the data a,b,c,... is 
any function f(a,b,c,... ). This function can be used as 
sufficient evidence of the presence of a particular data 
set, just like a person's signature on a check. It's not 
absolute proof of the presence of the data, however. 

The signature analysis technique was introduced in 1977 
[Ref. 27]. This technique should only be used when it is 
not feasible to compare test result data against actual 
data. There is no advantage to using signature analysis if 
the actual data is available at the same rate and in 
synchronism with the data being tested. It is a useful 
tool when properly utilized [Ref. 28]. 

Regarding the concept of design for testability, it 
falls between the ad hoc and the structured approaches for 
testable design. It is well-suited to bus structure archi- 
tectures, in particular, those associated with microcom- 
puters. The key to signature analysis is to design a 
network which can excite itself. Such a network could be 
microprocessor-based boards, since they can stimulate them- 
selves using the intelligence of the processor driven by the 
memory on the board [ Ref. 8] . 

1. Signature Anal vzincr 

The initial part of the approach is a linear feed- 
back shift register (LFSR). An example of a 3-bit LFSR is 
shown in Figure 2. 6 . This linear feedback shift register 
is made up of three latches. The upper exclusive-or gate 
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takes its inputs from the second and third bit in the shift 
register and the result is the input to the first latch. A 
LFSR counts for different initial values. 




Fegister 



Figure 2.6 A Linear Feedback Shift Register. 

For larger shift registers, the maximal length of 
the linear feedback configurations can be obtained by 
consulting tables in [Ref. 29] to determine where to tap off 
the LFSR to perform the exclusive-or function. Only 
exclusive-or blocks can be used, since this preserves the 
linearity. The Signature Analysis procedure is external to 
the board and a probe is used to probe a particular net on 
the board as shown in Figure 2. 7 . 

Let us suppose a bit stream of length n is fed to a 
serial data input line. There are 2 n possible combinations 
of data streams and each one will be compressed to one of 
the 2^ possible signatures. An LFSR has the property of 
equally distributing the different combinations of data 
streams over the different signatures [ Ref. 30] . For 
example, for n = 3 each data stream will be mapped to a 
distinctive signature (one-to-one mapping). 

For n = 4 exactly two data streams will be mapped 
to the same signature. Thus, for a particular data stream 
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Figure 2. 7 Use of Signature Analysis Tool. 

(good response), there is only one other data stream (a 
faulty output response) that will have the same signa- 
ture;!, e, only one faulty response out of 2 4 - 1 possible 

faulty responses will not be detected. 

In general, for any response data stream of 
length n > 4, the probability of missing a faulty response 
when using 3-bit signature analyzer is 

r\-3 . 

Z -1 -w 

= for n >> 4 

Z a -i 

It has been shown that the probability of detecting 
one or more errors is extremely high if a 16-bit LFSR is 
used [ Ref. 6] . 

The question is: if there were errors present at one 

or more points in the string of observations of that 
particular net of the board, would the value stored in the 
shift register (for each latch) be different than the one 
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Figure 2.8 Compact Testing. 

for the good machine ?. For each compression function f 
shown in Figure 2. 8, there is a slight probability that a 
response R1 different from the fault-free response RO which 
will be compressed to a form equal to f(RO),i.e. , f(Rl) = 
f(RO). If this happens, the fault causing the device under 
test to produce R1 instead of RO won't be detected. 

2. Advantages 

The major advantage is that this approach does away 
with the requirement for the actual data at the actual rate 
and in synchronism, and the requirement for testing of 
functionality. This reduces the cost [ Ref. 28] . 

The hardware to compute typical signature functions 
is inexpensive, and can be fast, while at the same time 
permitting the go/no-go decision to be made slowly at 
software speeds [Ref. 28]. 
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3. Disadvantages 



The major disadvantage of signature analysis is that 
it is difficult to derive any information from the signature 
beyond a yes/no decision. It is hard to diagnose failures 
from the failing signature. Consequently, a failure in one 
node will cause failures to be observed at any other nodes 
[Ref. 28]. 

Most signature functions involve a tradeoff between 
the probability of error detection and diagnostic capa- 
bility. For example, transition count based functions 
provide better diagnostic capabilities than the popular 
polynomial function; the latter provides a higher prob- 
ability of error detection, but knowing the logical distance 
between the expected signature and the failing signature 
unfortunately provides no knowledge about the distance 
between the expected data and the failing data either in 
time ( indicating when the failure might have occurred) or in 
space (as to how wrong the failuring data was) [Ref. 28]. . 

Another problem with signature analysis is the 

r 

volume of information that is contained in the signatures, 
even though this is substantially less than the volume of 
information . continued in the actual data stream itself. On a 
device under test with 1000 nodes, this implies a similar 
number of measurement [ Ref. 28] . 

4. Other Techniques 

There are extensions which use some other tech- 
niques in combination with signature analysis. The scheme 
proposed in [Ref. 31], called Pseudo-Exhaustive Testing 
using Signature Analysis, provides a function independent 
testing sequence for sequential machines. Signature and 
Parity Testing Techniques can be combined to solve the error 
masking problem which arises during the testing of multiple 
output circuits. Encoding the contents of the compacting 
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LFSR device using linear block codes is done to recognize 
combinations of parity faults in the multiple outputs of the 
function [Ref. 32]. 

Despite the possibility of missing an error which is 
very small (on the order of 0.002 percent), the Signature 
Analysis technique requires only very simple hardware 
circuitry and a small amount of memory for storing the good 
signatures. It is also not sensitive to the order of the 
test pattern. Signature Analysis, like any other tool, has 
its advantages and limitations but it is useful for testing 
if properly applied and combined with other techniques. 



E. CAD/CAT 

Computer-Aided Design (CAD) of integrated circuits has 
had various interpretations as a function of time and defi- 
nition source. These interpretations range from use ' of 
simple, interactive graphics and digitizing systems to indi- 
vidual programs used for circuit or logic simulation, mask 
layout, and data manipulation or reformatting. The computer 
aids or tools provide the designer with a rapid and orderly 
method for combining and evaluating design ideas and relieve 
the designer of numerous routine and design steps. The use 
of computer aids in the layout of IC masks essentially 
proceeded along two approaches: interactive graphics systems 
and automatic layout based on standard cells. Early interac- 
tive graphic systems provided a method for capturing the 
design by recording coordinate information by manually digi- 
tizing and editing data. Methods for superimposing mask 
layers, scaling, enlarging, contrasting, and reviewing the 
results were expanded to provide fast, sophisticated drawing 
commands for constructing, editing, and reproducing complex 
figures. [Ref. 33] 
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In developing VLSI systems with a CAD environment, 
system engineering and information processing tasks of many 
people must be coordinated. The coming generation of inte- 
grated CAD environments is changing the work habits of indi- 
vidual designers and operation of VLSI system development 
organizations. On the other hand, overcoming the complexity 
of advanced VLSI systems requires substantial effort in 
organizing many people with increasingly specialized skills. 
[Ref. 34] 

Some unique CAD principles have been developed and 
proven to be very effective when used in conjunction with 
other engineering management concepts. As stated in [Ref. 
35] , a number of these principles are summarized below: 



1. System Aspects 



1. Successful CAD optimizes both individual programs and 
the CAD system. 

2. The overall CAD system has a higher productivity than 
any individual program. 

3. Consistent engineer interfaces are imperative. 

4. A data base system can improve CAD operation, but an 
enormously large data base may make the system very 
unwieldy and difficult to use. 

5. An expert-system may be complex, but a simpler system 
may have only limited usefulness. 



2. Software Development 



1. The support and tuning of programs are often larger 
tasks than the original development task. 

2. Interfacing and debugging is never complete. 

3. There is a minimum level of CAD support required, 

irrespective of the number of people using the 
program. 

4. Onlv develop a program if it makes a major 

contribution. 

5. Expect programs to change and eventually die. 

6. Make sure when starting a project that the capability 

will be needed when the projecc is concluded. 
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3. 



Hardware Selection 



1. There is no ODtimum computer for CAD; if there were, 
it would not be optimum in six months. 

2. Hardware costs less than software. 

3. Distributed computing means more than machine to 
machine communication. 



4. CAD Impact on Design 



1. CAD must be user driven. CAD must support the present 
user while developing for the future. 

2. The CAD activity is not a good controller of the 
design process and cannot effectively mediate between 
designers. 

3. Design is a creative process and the designers' 
creativity often leads to differences in design 
approaches. 

4. Engineers stop verifying and optimizing their project 
only when it is too painful to 'continue. 
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Figure 2. 9 VISTA Software Overview. 



Sophisticated CAD systems have been developed. As a 
typical example of CAD for VLSI we provide an overview of 
the VISTA (VLSI Simulation Test and Artwork) system which 
was introduced in [Ref 35]. Most of the principles above 
were experimentally generated through the experience of 
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designing and implementing the VISTA system whose software 
configuration is shown in Figure 2.9 from [Ref. 35]. A 
VISTA workstation consists of a physically small computer 
with approximately 1/4 the CPU power of the midi-computers 
being used. Each workstation is connected to four intelli- 
gent terminals ( Figure 2. 10 ) two of which are color 
graphic stations. The entire VISTA CAD system may be run on 
the workstation as well as on the larger midi computers. 
Larger mainframes are used for batch jobs which consume 
extensive computer time. The system is extremely flexible 
allowing a user to share computer resources as well as 
files. [ Ref. 35] 




Figure 2. 10 VISTA Hardware Configuration. 



The design methodology of' custom VLSI devices, 
however, may yield data for test use and may also allow the 
device designer to use that data in a semiautomatic manner 
on low-volume prototype devices. A successful Computer-Aided 
Testing (CAT) system recognizes that design data exists in 
many forms during the IC design lifecycle. While device 
designers may not have a test background, the test expertise 
may be shared by extracting functional pattern data from the 
IC design flow and transferring it to the appropriate 
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production test and/or benchtop debuging equipment. Usually 
this means capturing the test vectors that were used during 
logic simulation and reusing them for test purposes. This 
ensures that prototype IC devices can be functionally veri- 
fied with the same test patterns used during logic simula- 
tion. In CAT design, extendability of the system into other 
simulation and testing environments is an important consid- 
eration. A properly designed, intermediate pattern format 
standard would allow a CAT system to grow into new simula- 
tion and test environments without impacting an existing 
system. A new logic simulator or piece of test equipment can 
be supported by developing a format-conversion program 
without re-doing major portions of the existing system. This 
concept is important when testing organizations support a 
variety of IC design methodologies. [Ref. 36] 



F. TEST EQUIPMENT AND METHODS 

Circuit complexity, a large number of inputs, clock 
signals and outputs, or the multitude of possible states may 
make manual testing prohibitively time-consuming. In general 
it will be necessary to use a computer to exercise the chip. 
A simple test system is illustrated in Figure 2. 11 . 

Properly defined test vectors, provided by the 
computer's output port, are applied to the input of the 
device under test. The response vector of the device under 
test is compared to a stored correct response by the 
computer which is programmed to respond with an error 
message upon detecting deviation from the expected pattern. 
[Ref. 1] 

A minimal test system could consist of a general purpose 
test board with a tri state driver and read buffer connected 
to each pin, a couple of latches to store the state of 
the input and/or output variable at each pin, and a 
communication interface to the computer. [Ref. 1] 
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Figure 2. 11 Simple Test System. 

A software-based testing system might not be fast enough 
to capture some quickly changing response vectors, or it may 
have trouble exercising a complex device which may require 
some minimum clock rates for proper operation. Higher speed 
performance can be obtained with a parallel link to the 
computer. ( If the excitation vector is wider than the typical 
8 or 16 bit link to the host computer, the vector maybe 
transmitted in several pieces and assembled in a set of 
registers on the interface board). Even higher I/O vector 
speeds can be obtained by moving more functions from 
software into hardware. An improved tester could use 
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semiconductor memory to store the excitation (test) and 
response vectors of a whole test sequence. The captured 
response vector can later be analyzed at a slower rate. 
[Ref. 1,37] 
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Figure 2. 12 Hardware Approach to IC Testing. 



The tester shown in Figure 2.12 from [Ref. 1] is a 
peripheral device to the host computer. The two advantages 
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of self contained testing hardware are: first it allows 
higher testing speeds and second it frees the computer to 
perform other tasks while testing is in progress. The exci- 
tation or test vector for the device under test can be 
understood as a set of control words emanating from a 
computer's control unit, with the result vector out of the 
device acting as a condition vector to this control unit. 
The tester thus takes the form of a microprogrammed 
controller. A tester based on this principle can exercise 
very complex devices due to its inherent ability to make 
logical decisions based on some of the results. When the 
test is concluded, relevant results are as before stored in 
a result RAM, and the host computer is signaled to fetch 
them. This kind of tester can be adapted to new tasks by 
changing the microcode stored in the excitation RAM shown in 
Figure 2. 13. The tester may even do suitable branching 
dependent on the outcome of a few preliminary tests. 
[Ref. 1] 

Almost any computer or microcomputer can be used as the 
host. The only requirement is that it has an accessible I/O 
port. The control unit for the tester could be built using 
one of the fast bipolar bit-slice microprocessors. The 
proper custom made interface board between the chip and the 
test system has to be built and the test routines have to be 
written. [Ref. 1 ] 

One example of a VLSI test architecture is a Z8001-based 
single board computer with some additional memory and logic, 
and an interface to the device under test ( Figure 2. 14 from 
[Ref. 38] ). The process involves creating a test program 
using the device assembler on a host computer. The program 
is downloaded to the VLSI tester where it executes. The 
results are captured in a trace memory and are sent back to 
the host. The host software then translates the results into 
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Figure 2. 13 Microprogrammed IC Tester. 

a device-oriented test pattern. The operating system allows 
the user to load programs to and from a host computer, to 
execute programs and to display or edit device under test 
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registers, memory and test results, 
memory blocks. [ Ref. 38] 



and to compare or move 
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G. TEST SOFTWARE 



Testing complex LSI and especially VLSI circuits 
requires the generation of a large number of test vectors. 
To address these problems, a test software system has been 
developed and introduced in [Ref. 39]. The test software 
system consists of three software elements shown in Figure 
2. 5 . The first element of the system is the Test Vector 
Assembler. It accepts symbolic microcode written in a 
register transfer language with many higher level 
constructs. These higher level constructs allow the auto- 
matic generation of large numbers of test vectors from very 
short and simple specifications. 




Figure 2. 15 CAT System-Software Overview. 



The second element of the test software system is the 
Test Vector Simulator which contains a software model of the 
device under test data paths and storage elements. The model 
computes the next state and output configuration of the 
device under test based on its current state and the test 
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vectors applied. As a result, the test vectors specified in 
the binary microcode are augmented with the corresponding 
expected responses, thus completing the test vectors. 

The third element of the test software system is the 
Test Vector Exerciser software. This program facilitates 
interactive control of the actual execution of the test. It 
also has special features to aid the test engineer in 
performing fault isolation and diagnosis. 

The test software system is implemented on an Intel 
microcomputer development system computer which is the basis 
for an in-house LSI/VLSI test system, the QTS-IV, The 
computer itself is based around an Intel 8080 microprocessor 
with 64K bytes of memory, dual single density floppy disks, 
CRT/keyboard, line printer and integrated circuit test head. 
All programs are written in PL/M, an Intel language, and 
they run under the ISIS-II Operating System. [Ref. 39] 

Besides software systems, there are modern test 
languages. The extensions that make the following high level 
languages into test languages are discussed and introduced 
in [Ref. 40,41,42,43,44], Pascal can be extended for test 
pattern generation and special purpose controller program- 
ming which are tasks that are specific to ATE. Pascal-T is 
also a test language that permits unlimited control of test 
functions while retaining the ease-of-use features of a high 
level language. PLT (Programming Language for Testers), 
designed by IBM, allows the user to perform functional 
testing of a product in an event driven mode at the 
functional speed of the product [ Ref. 44] . 

ICTEST is an algorithmic language for describing 
functional tests of digital integrated circuits [Ref. 45]. 
The test stimulus and response specification is high level, 
with the ICTEST system handling the translation into a test 
vector. The idea behind the ICTEST system structure shown in 
Figure 2. 16 is to unify testing and simulation. The designer 
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writes one test description that can be compiled for any of 
the functional simulators and testers in the system. 
Currently, tests target to either of two simulators or three 
testers. 
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Figure 2. 16 The ICTF3T System. 



ICTEST itself, the interface programs, and the esim and 
tsim switch level simulators run on a VAX-11/780. The VAX 
communicates with the testers over serial links. The MINIMAL 
tester can test 40-pin devices at a maximum of 1000 drive or 
sense operations per second; the MEDIUM tester, 80 pins at 
100000 operations per second; the TEK tester, 64 pins at 
5000000 operations per second, all pins simultaneously. 
ICTEST is an embedding of testing features in the C 
language. C is an Algol-like language which is similar to 
Pascal. The full power of C is available for describing 
tests algorithmically. [Ref. 45] 
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H. ECONOMY OF TESTING 



In general there is always the possibility that a chip 
doesn't function as desired. This must be detected through 
testing and, if caused by a design flaw, the chip has to be 
refabricated and retested. These steps are illustrated in 
Figure 2. 17 . 




Figure 2. 17 Basic Flow of Test Process. 

There have been some studies concerned with modeling 
this process by using algebraic equations [ Ref. 
46,47,48,49,50]. The purpose is to determine the effective- 
ness of the process and fault coverage of the tester, and to 
estimate cost or throughput. 

If the cost is $0. 30 to detect a fault at the chip 
level, then it would cost $3 to detect that same fault when 
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it was embedded at the board level; $30 when it is embedded 
at the system level. With VLSI and the inadequacy of auto- 
matic test generation and fault simulation, there is consid- 
erable difficulty in obtaining a satisfactory level of 
testability. Thus, if a fault can be detected at the chip or 
board level, then significantly larger cost per fault can be 
avoided at subsequent levels [Ref. 8]. 

The drop in costs and the increase in throughput occur 
as detected faults drop no matter what kind of method is 
used [Ref. .46]. On the other hand, faults are not easily 
controlled, so much effort has to be spent to reduce them. 

Test program development has - become an increasingly 
complex and time consuming task and development costs are 
primarily dependent on programmer and machine time invest- 
ments. A remote program management approach has been 
proposed to save in manpower and test system utilization. 
The benefits and disadvantages of this programming approach 
are discussed in [Ref. 51]. 

Programmer effectiveness and selection of test strategy 
are also critical issues for testing. Important productivity 
gains can be made in a test organization by improving 
programmer effectiveness and selecting a best test strategy 
can provide maximum return on investment. These are studied 
and quantified in [Ref. 52,53]. 

It is recommended that critical circuit paths and area 
of possible marginal performance be clearly stated prior to 
testing. This is contrary to the common belief that only by 
revealing such areas of potential weakness is reliable 
testing demonstrated. Knowledge concerning possible circuit 
limitations allows tests to focus more on these areas while 
still providing general tests of circuit functionality. In 
this way, the overall effectiveness of testing can be 
improved and the cost decreased. 
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III. REQUIREMENTS FOR TESTING 



We have considered the most popular currently available 
approaches and some systems for testing of integrated 
circuits. It is observed that the functional test strategy 
is an appropriate approach in an academic environment which 
produces a few designs a year. This is why the introduction 
of hhe functional testing approach was left to this chapter. 
After examining the functional test strategy, it will be 
explained why we decided to use this approach. 



A. FUNCTIONAL TEST STRATEGY 

Functional testing is basically a test strategy which 
attempts to verify correct functional operation of a digital 
circuit according to its specifications. A complete test can 
be generated considering only the desired operation of a 
good system. What is expected from the functional testing 
approach is that complex systems can be quickly tested to 
see if they perform their intended functions. Functional 
faults with respect to functional specifications can be 
tested by using a representation of a circuit higher than 
its gate level. (We have not encountered any clear and 
strong attempts to formalize functional testing). Generally 
speaking, functional testing is the differentiation of 
faulty integrated circuits from good circuits which satisfy 
their functional requirements. An integrated circuit can be 
functionally tested by stimulating it with a carefully 
defined input test sequence and than comparing its response 
with a stored correct sequence. 
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B. WHY FUNCTIONAL TEST 



The exhaustive testing approach and the other methods 
derived from it often require an unacceptable amount of test 
time and memory space to go through all possible steps. A 
circuit with 24 inputs and 32 bits of memory has 2 i '~ or 
approximately 4 x 10^ different internal states. There are 
2^ or approximately 16 x 10 6 possible input patterns. An 
exhaustive test would require approximately 7 x 10 tD test 
vectors. With the capability of 10 million test steps ( 10 
MHz) per second, it would take more than 200 years. Thus, 
exhaustive testing is good for only small systems. 

Fault simulation and fault modeling techniques are very 
useful in describing physical failures in small and medium 
scale circuits (especially TTL). However, today's circuits 
on a chip may not have a simple correspondence with gate 
level logical descriptions. There are many cases where 
failures cannot be represented by the stuck-at models [Ref. 
10] . Representation of a single faulty circuit which has no 
simple gate level correspondence would require a large 
number of gates. On the other hand, stuck-at models are the 
only computationally efficient and quantitative measure of 
test effectiveness [Ref. 14]. But when we consider today's 
complex LSI/VLSI circuitry this method is time consuming and 
requires detailed gate level descriptions of circuits. Since 
a detailed circuit description of a chip is often not avail- 
able, functional testing becomes important. 

Signature Analysis seems a more economical and attrac- 
tive way to perform testing because of data compression and 
the requirement of very simple circuitry. Even though the 
volume of information contained in this method is less than 
the actual data stream itself, it still implies time 
consuming measurements. 

Once we agree on the functional test strategy which is 
the best for our environment under today's circumstances, we 
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can first examine ways of using simulation data as test 
and reference vectors and then consider possible basic 
characteristics of a functional tester. 

C. USING SIMULATION DATA AS TEST AND REFERENCE VECTORS 

One way to extract test and reference data vectors is to 
drive a tester with ESIM files which are generated during 
the design layout phase. This approach, illustrated in 
Figure 3.1, is designed and implemented (except for the 
communication and hardware interfaces between microcomputer 
and tester) in [Ref. 54] as a thesis project. The ESIM 
files for a particular VLSI circuit consist of pin designa- 
tions, initialization vectors, clocking sequences, test 
inputs and the corresponding output vectors. Test data from 
ESIM files are extracted by an "Extract Test Data" software 
subsystem. This software program is implemented on a 
VAX-11/780 computer system in order not to be restricted by 
the memory capability of a microcomputer. This program 
changes the available node data into the test vector format, 
and writes out these vectors into an external file. This 
data file is then converted into the microcomputer operating 
system data format and then transferred to an 8" floppy 
di sk. 

The VLSI circuit is simulated either from test files or 
from data entered through the keyboard interactively. After 
initialization of the tester and the device under test, each 
test vector is applied to the device under test and the 
resulting response is compared with the given reference 
vector. 

This method is useful but it is limited by a test 
capability that can only test VLSI circuits for which 
corresponding ESIM files exist. 



50 



Esim Data File 



Keyboard 



MicrocomDuter 



Tester *" 



DUT 



Test Results 

Simulation 

Vector 



Figure 3.1 Automated Tester for VLSI. 

D. BASIC CHARACTERISTICS OF A FUNCTIONAL TESTER 

A typical test plan indicates five basic sequences of 
actions as below; 

1. Generate the (next) test vector 

2. Transmit the vector from tester to device under test. 

3. Process the test vectors through the device under 
test. 

4. Transmit the response from device under test to some 
response analysis circuit or tester. 

5. Deduce the received response. 

A sequence of these steps may be executed once for every 
test vector and every step is executed in one clock cycle. 
Keeping this basic plan in mind the most significant 
required characteristics of a tester are: 
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1 . 



Sufficient test speed -- A test system with high soeed 
memory buffering facilitates applying the test vectors 
to the device under test. A test system should also 

be capable of testing circuits at their original oper- 
ating speed. 

2. Sufficient number of I/O pins -- As an example the 0M2 
data path chip has 64 pins [Ref. 55]. Many of today's 
VLSI chips have more than 300 pins. 

3. High speed memory buffering with sufficient death. 
Today s CMOS memory RAMs have access times of about 55 
nanoseconds. The depth must allow one to apply test 
vectors to the device under test without interruption 
caused by the need of memory reloading. 

4. Accurate timing : The timing accuracy must satisfy a 

delay time of 500 ps or less. The master test clock 
generator circuit and other clock circuits in the 
tester should be designed to give this accuracy. 

5. Ability to provide clocks to the device under test. 

6. Ability to synchronize the device under test to the 
tester. This may be accomplished by designing as much 
as possible of the tester with custom VLSI circuits.. 

7. Avoid noise and skew problems which affect tester 
speed. 

8. Expandability and flexibility. The tester can be 
easily reconfigured to improve its capabilities as 
well as to satisfy future requirements. 



52 



IV. FOCUS OH TWO BASIC APPROACHES 



Having agreed on the functional test strategy which is 
the best for our environment under today's circumstances, we 
can start to examine two candidate approaches to design a 
functional test system. Chapters Two and Three provide the 
basic guidelines. 



A. GENERAL PURPOSE MICROPROCESSOR AND BUS INTERFACE 
1. Obi ective 

The purpose of this section is to examine the 
capabilities of a system shown in Figure 4. 1 and to deter- 
mine its hardware and interface requirements. 




Figure 4. 1 Microprocessor Based Test System. 

2. Pi scussion 

The microprocessor controls the complete test 
process. The bus interface provides necessary connections 
between microprocessor and device under test. We have 
chosen two well known microprocessors for comparison. They 
are the Intel 8086 and the Motorola 68000. Table 3 lists 
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some of their features and the buses which support either or 
both of these microprocessors are listed in Table 4 . 



TABLE 3 

SOME FEATURES OF 8086 AND 


68000 




8086 


68000 


word size 


( data/instruction) 


16/16 


16/16 


direct addressing 
range (words) 


1 MBytes 


16 MBytes 


max clock freq. 
( MHz/phases ) 


5/1 


8/1 


on chip clock 


yes 


no 


DMA capability 


yes 


yes 


package size 
( pins) 


40 


64 



The test system could operate as fast as the 
execution of memory fetch and output write followed by an 
input read and memory write. These steps take 40 clock 
periods for the 8086 and 40 clock periods in the absolute 
addressing mode for the 68000. For only 16-bit test vectors, 
a maximum test frequency of approximately 125 KHz for an 
Intel 8086 operating at 5 MHz is achievable. This translates 
to approximately 200 KHz for an Motorola 68000 operating at 
8 MHz. Test vectors of 64-bits would require four of the 
previous cycles for each test cycle, indicating a maximum 
test frequency of approximately 30-50 KHz. These figures are 
dominant and no further calculation is necessary since the 
buses are not slower than these data transfer speeds. Some 
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other combinations could increase the speed but the result 
is still not a sufficient test speed. 





TABLE 


4 




TECHNICAL FACTORS FOR VARIOUS BUSES 




MULTIBUS 


VME 


S-100 


controlling 

body 


IEEE 786 


Motorola 


IEEE-P961 


VLSI support 


Yes 


Yes 




processors 


8080 , 8085 
8086, Z80 
80186,80188 
80286, Z8000 
68000,6800 
6802,6808 
16032 


68000 

80186 

16032 


8080,8085 
8088, Z80 
80186,80286 
6800,68000 
16032 


address 

width 


24 


16,24,32 


16 or 

24( expanded) 


data width 


8/16 


8/16/32 


8/16 


bandwidth 
( MBytes/sec ) 


5/10 


6/12/24 


6/12 


interrupt 

lines 


8 


7 


100 


interrupt 

ack 


polled 


daisy 

chain 


polled 


arbitration 


serial or 
parallel 


serial or 
parallel 
with daisy- 


parallel 

chain 



We have seen here that controlling the complete test 
by a microprocessor is not fast enough. As discussed before 
in Chapter Two, the way to increase test speed is to build a 
separate tester which has a controller and its own memory 
elements. At this point we will consider Katz's design frame 
v/hich is proposed as a prototype testing facility in 
[Ref. 56]. 
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3. 



Katz ' s Design Frame 



When a fabricated chip is received, it is not easy 
to communicate with it. It must be supported for memory and 
communications. As stated in [Ref. 56], there is a need for 
standard design frames for which a user's circuit easily 
becomes a prototype system by inserting it into the frame. 
The design frame must provide system capabilities like 
memory, I/O ports, timers, standard bus, etc. This makes the 
testing and debugging of fabricated chips very easy and 
saves time. 

Katz's design frame is based on the Intel iSBC 
86/12A single board computer whose architecture is shown in 
Figure 4.2, [Ref. 57]. The standard board contains an 8086 
microprocessor, 32K bytes of dynamic RAM, three programmable 
I/O ports, an RS-232 interface, programmable timers, an 
interrupt controller, provision for 16K bytes of ROM, and 
Multibus interface control logic [Ref. 57]. A feature of the 
iSBC 86/12A is that the memory is dual ported between micro- 
processor and the Multibus so that a master 8086 on one 
board can deposit and examine the memory contents on a slave 
board. 



Katz's design frame is a cannibalized iSBC 86/12A 
board and a bus controller that emulates the 8086 's own bus 
interface unit [ Ref. 56] . The 8086 is simply removed and 
the user circuit/bus controller combination chip is plugged 
into the 8086 socket as shown in Figure 4. 3 from [ Ref. 56] . 
The bus controller acknowledges request signals and gener- 
ates bus control signals that are identical to those of the 
8086. The other subsystem on the board ( I/O ports, memory 
chips. Multibus controller, etc. ) behave as though they 
are interfaced with an 8086. 
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Figure 4.2 ISBC 86/12A Block Diagram. 



As shown in Figure 4. 4, a master slave configuration 
of two boards communicating through the Multibus seems prom- 
ising as a test system. The master board can download data 
into the slave's memory and read data placed in the memory 
by the slave. This makes it possible to test fabricated 
chips. 



4. Results and Analysis 



Using the 

with a maximum test 
instruction queue 
instruction cycle, 
observed in speed, 
controller uses 12 



design frame approach provides a tester 
speed of approximately 90 KHz. A 6-byte 
provides pre-fetching and reduces the 
This is why little improvement is 
Since the 8086 has 40 pins and the bus 
of them, the tester would have 28 test 
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Figure 4. 3 The Design Frame. 

pins. The iSBC board has 32K x 8 bits RAM and it is also 
expandable to 64K bytes with the iSBC 300 32K bytes 
Multimodule RAM option. The power requirement is about 55 
Watts. [ Ref. 57] 

The advantage of this approach is the capability of 
easily communicating externally through the Multibus. In 
this way the tester can be interfaced to a design station. 
But the test speed and the number of test pins on this 
tester are not sufficient. 



58 



DUT and Bus Controller 




Figure 4. 4 Master Slave Configuration. 

B. A CUSTOM VLSI TEST CONTROLLER AND BUS INTERFACE 

Let us now consider another approach. During a course on 
a VLSI design a simplified design of an integrated circuit 
tester was developed to reveal the advantages and 
disadvantages of this approach. 

1. Statement of Design Goal 

The goal is to design an integrated circuit tester 
using nMOS technology by implementing the simplest testing 
approach: apply properly defined test or excitation vectors 

to the device under test and compare the outputs to a stored 
correct response. A simplified diagram of the tester is 
shown in Figure 4.5 All major components are available from 
Mathews and Newkirk's designer's library [Ref. 23]. 
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Figure 4. 5 Functional Diagram of IC Tester. 



60 



2. Manor Components 



There are two basic components in this design; 
memory cells and a pla cell. 

Memory Cell : 

The memory RAM is composed of three cells which are 
an Address cell, an Interf acePair cell and a RamPair cell 
( Figure 4.6). 

RamPair ( 28 x 33 ) 

Read from RamPair: B^ 0 has to be precharged and when 

the Readbar input is clocked the inverted value stored in 
ram cell appears on B* w . 

Write into it: B(^ is driven to the desired value 

and Writebar is clocked. 




Sense 



Precharge 

Wr i i e_Jcar 
Sei 

Read_bar 



Figure 4. 6 An Example Memory Subsystem. 
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Interf acePair ( 33 x 128 ) 

This cell provides the circuitry necessary for the 
outside world to access the ram cell. Interf acePair 
precharges B^ 0 during first clock phase. It reads out during 
the second clock phase when Sense is clocked and writes in 
during the second clock phase when Drive is clocked. 

Address ( 24 x 137 ) 

This is a driver for the Read and Write control 
lines. Address qualifies the Readbar and Writebar clocks 
with the Selbar line and provides supperbuf f ered drive. 

Pla Cell : 

The pla cell is used to implement the controller, 
which is a simple sequencer in this case. All the inputs and 
outputs are clocked. 

3. Structural Floor Plan 

The cells used in this design are listed in Table 5 
and the floor plan of the tester is shown in Figure 4. 7. The 
system has a total of 32 interconnection pads. The boundary 
of the chip is 1186 by 1035. The pla controller and RAMs are 
placed in the middle. PadMux pads are used is to reduce the 
number of pads required. A PadMux cell acts like an input 
pad when its OUT/INbar input is low, and like an output pad 
when OUT/INbar is high. The final layout of the tester is 
shown in Figure 4. 8 . 

The power consumption of this design is estimated by 
power estimation program (Powerest). Its estimated average 
power is 99. 36 mWatts and the maximum power is 178. 98 
mWatts. 

4. Functional Specification 

The host computer loads the desired 8 bit long 
vector into the excitation RAM. After this is done, the host 
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TABLE 5 

CELLS USED IN DESIGN OF TESTER 



Name 


Size 




Amount 


cif : 


PadGnd 


100 


X 


106 


1 


206 


PadVdd 


80 


X 


100 


1 


207 


Pad0ut4 


100 


X 


145 


1 


204 


Padln4 


100 


X 


106 


20 


205 


PadMux 


100 


X 


180 


9 


282 


RamPair 


28 


X 


33 


24 


505 


Interface 


33 


X 


128 


6 


506 


Address 


24 


X 


137 


8 


503 


InvSB4 


20 


X 


42 


1 


234 


Pla 


148 


X 


79 


1 


501 



computer initializes the controller. The excitation RAM 
supplies the next address and enables the controller to 
sequence through testing. A 4-bit vector is applied to the 
input of the device under test. A 4-bit result vector from 
the device under test is stored in the result RAM. Nand 
gates are used to implement the multiplexer. It is used to 
detect the case when all bits of the result vector are low. 
If the condition select bit is programmed to be high at any 
desired sequence of testing, this high signal enables the 
multiplexer. So whenever the result vector bits are all low 
after the multiplexer is enabled, the output of the multi- 
plexer terminates the testing sequence. Either in this 
condition, or when the test sequence is completed, the 
controller interrupts the host computer. The host computer 
gets the result vectors from result RAM , analyzes the 
results and makes a decision about the device under test. 

The only testing simulation done was the test of 
writing into and reading out of the RAMs. (Complete func- 
tional behavior of the tester depends on the interfaces with 
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Figure 4. 7 Floor Plan of Tester. 
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the host computer, and the device under test is very 
complicated to simulate). Simulation results, however, show 
that the RAMs are functioning correctly. 

5. Results and Further Directions 

This tester has approximately 1 MHz test speed, 4 
bits memory depth and 9 I/O pins. This methodology is 
effective but not practical from the application point of 
view. On the other hand, it can be easly expanded. The 
multiplexing idea can be extended to a desired complexity. 
The RAM dimensions can be increased to a desired size by 
iterating more memory cells. 

However, we note that it is really not desirable to 
design a complete tester as a custom VLSI circuit. The 
tester circuit itself will be complex and hard to test. It 
also violates flexibility and expandability requirements. 
It is observed that a better way is to design a controller 
and other necessary internal interface circuits as a custom 
VLSI circuit. Separate high speed CMOS RAMs can be used as 
excitation and result memories . This increases flexibility 
and makes tester speed depend on basically the access time 
of the memory. 
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Figure 4. 8 Final Layout of IC Tester. 



66 







V. PROPOSED TEST SYSTEM ARCHITECTURE 



So far two testing approaches have been examined and 
operating characteristics have been derived. A test system 
architecture will now be proposed to meet these guidelines. 
The logical structure of the controller and interface 
requirements between the tester and device under test will 
be examined. The speed, memory depth and the number of the 
I/O pins of the tester are basic considerations. 

A system configuration of the proposed test system is 
presented in Figure 5.1. A controller, memory board, 
programmable clocks, pipeline registers, and device under 
test board are parts of the tester. It is a combination of 
two basic approaches. The microcomputer can be a Z-100 or 
IBM PC and the microprocessor can be an Intel iSBC 86/12A 
single board computer. The microcomputer provides the oppor- 
tunity for a high-level interface with the other portions of 
the tester and through the ethernet to other computer-aided 
design systems. This allows, for example, test programs to 
be written in high-level- languages and a menu-driven user 
interface. This is the basic picture of the proposed test 
system architecture. First the functional tester of the 
system will be presented and then the presentation of the 
system will be completed with a scenario based on test 
consideration for the 0M2 Data Path Chip designed at Caltech 
[Ref. 55] . 

A. HARDWARE DESIGN CONSIDERATIONS OF TESTER 

A possible logical configuration of the functional 
tester is shown in Figure 5. 2 . The tester can communicate 
with the microprocessor via the Multibus. The microprocessor 
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ETHERNET 




Figure 5. 1 Proposed Test System. 

downloads test vectors into the excitation RAM before the 
test phase. The test phase is considered as the process of 
applying test vectors and receiving response vectors without 
interruption. The microprocessor initialises the controller 
to start the test phase. Before getting into more detail let 
us examine the basic blocks. 
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Figure 5. 2 Configuration of Functional Tester. 

1. Controller 

The controller must provide at least three 
functions. First is the the generation of control signals 
for the timing and control logic circuit and the device 
under test interface circuit. The second function is address 
generation for the memory RAM. The third is generation of an 
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interrupt signal to the microprocessor when the test phase 
is completed. 

The required control signals from the controller are 
addresses for the RAM, start test phase signal, interrupt 
signals to the microcomputer, the strobe signal to pipeline 
registers, RAM write and read signals, and so on. Complex 
address generation to provide branching and conditioning is 
not considered here. Simple address generation will be 
sufficient for our purposes. Since it is possible to create 
test vectors using high level language programs on a micro- 
computer, trying to make logical decisions based on some 
results during the test phase would only cause confusion and 
complexity. At least at the begining, straightforward 
address generation is preferred. The controller can be 
designed as a PLA implementation of a finite state machine. 

2. Memory Boards 

Memory boards buffer the data vectors prior to 
transfer to and from the host computer and the device under 
test. As discussed before, there must be two different 
memory blocks. The first one is the excitation or test 
vector RAM and the other is the result RAM. Typical commer- 
cially available 2K x 8 bits CMOS random access memory 
elements have approximately 55 nanoseconds of read and write 
cycle time. As a first approximation, this means that an 18 
MHz test speed is possible. During the test phase, the 
write signal to the excitation RAM and the read signal to 
the result RAM may be inhibited by control signals. This 
makes the excitation RAM a read only memory and the result 
RAM a write only memory during the test phase. So test 
vectors could be applied to the device under test and result 
vectors could be written into the result RAM without 
interruption. 
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To increase the depth, memory elements could be 
added in pairs and address lines could be increased, such as 
going from 2K x 8 bits to 4K x 8 bits. Increasing the width 
of the test vectors for example from 2K x 8 bits to 2K x 16 
bits could be done by adding one more memory element. 

3. Programmable Clocks 

The programmable clocks board must supply necessary 
clock signals which are used by the tester and the device 
under test. Binary counters can be used to generate program- 
mable clocks and an oscillator drives counters. For example, 
if two four-bit binary counters are cascaded, the resulting 
eight-bit counter would allow a count range of 0 - 255. A 
clock programmable in small increments, such as 10 nanose- 
conds or less, is desirable. An eight-bit counter with 10 
nanosecond increments would permit programming of 0 - 2560 
nanoseconds giving a range of about 400 KHz. The output of 
the counters would be compared to the output of storage 
elements (i.e. latches) by a comparator. These latches 
would be loaded with desired count values. When the compa- 
rator detects a match, a pulse is produced at the output of 
the comparator. This pulse toggles a flip flop and this 
produces, a transition of the programmable clock. 

In order to program a clock over the entire cycle at 
frequencies as low as 100 KHz, the programmable clock would 
require a count range of 0 - 1000 which means a 10 bit 
counter. The resolution considered here is 10 nanoseconds. 
To improve the resolution this time increment must be as 
small as possible. A VLSI circuit design can be considered, 
for example, which would use an internal clock of frequency 
100 MHz or greater to produce a clock programmable in 10 
nanoseconds or smaller increments. 
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4. 



Interfaces 



The first consideration here is the interface of 
device under test to the tester. Connecting test data lines 
coming from memory RAMs to device under test is possible by 
using pipeline registers. Typically, the set-up and propaga- 
tion delay time of an SN74373 is approximately 15 nanose- 
conds. This is important because the speed of the tester is 
also dependent on this delay as well as memory access time 
and the address generation time for memory. 

The device under test interface board should allow 
routing any of the data lines received from RAMs, program- 
mable clock lines, Vdd, and GND to any pin of the device 
under test. The device under test interface and pipeline 
registers can be designed together as a custom VLSI circuit. 

An arbitration logic circuit must simply allow the 
Multibus and the controller to share memory address lines 
and separate address lines from the Multibus interface 
circuit and connect them to the controller before a test 
phase is started. 

The timing and control logic circuit must provide 
all signals necessary to control the dynamic RAM ( i. e. read 
and write signals, etc. ), a refresh timer and perhaps 
refresh counter. For instance, one of the functions of the 
Intel 8202 Dynamic RAM Controller is to provide these 
control signals [ Ref. 58] . 



B. SUMMARY 

The expected characteristics and capabilities of the 
proposed test system can be summarized as follows. The 
maximum possible test speed would be approximately 10 MHz. 
As stated before, approximately 55 nanosecond memory access 
time, approximately 15 nanosecond delay time of pipeline 
registers, and about 25 nanosecond address generation time 
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make the 10 MHz approximate test speed possible. Memory 
depth could be expanded up to 1M byte since 20 bit address 
lines are available. Up to 128 test pins could be provided. 
These figures are good enough for our purposes. For example, 
with such a tester it would be possible to test the 16 bit 
0M2 data path chip, [Ref. 55], which will be discussed next. 



C. DISCUSSION 

Testing of the 0M2 data path chip can be accomplished by 
this proposed test system. The OM2 16 bit data path chip 
contains 16 registers, an ALU, and a 16 bit shifter, and is 
designed as part of an LSI computer system, ( Figure 5. 3 
from [Ref. 55] ). The data path chip performs most of the 
data manipulation functions for the system. The operations 
are performed as directed by sequences of control microin- 
structions, which are fetched from a microcode memory 
using addresses generated by the controller chip. 

The 0M2 data path chip has two data ports for 
communication with the external system and a communication 
path to the controller chip. A block diagram of the OM2 data 
path chip is shown in Figure 5.4 from [Ref. 55], The data 
ports are tristate with either internal or external control. 
Communication with the controller consists of a 16 bit 
literal port and a single flag bit. Seven control bits 
come directly from the microcode memory. [Ref. 55] 

The data path chip has 64 pins, and runs on a single 
clock, generating (/^ and internally. When the clock is 
high, the internal buses transfer data. When the clock is 
low, the ALU is performing its operations. Microcode bits 
enter the data chip the phase before that code is to be 
executed. Therefore, the bus transfer code enters the data 
path chip when the clock is low, and the ALU code enters 
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Figure 5. 3 0M2 System Configuration. 

when the clock is high. The minimum required total clock 
period is about 135 nanosecond. [Ref. 55] 

Three programming examples are given and the program 
steps are listed in [Ref. 55]. The first is a 16 bit 
integer multiplication, second is parity generation, and the 
third shows how the data path can compute its own instruc- 
tion. These programs would be used for functional test 
vector generation. Necessary high level and assembly 
language programs can be written to create a test vector 
data file, download it to the tester, perform testing, get 
the result data from the tester, and deduce the results. 

The proposed functional tester could provide a 135 
nanoseconds clock to the device under test and perform the 
testing of the 0M2 data path chip. 
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Figure 5. 4 Block Diagram of The Data Path Chip. 
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VI. CONCLUSION 



Testing an integrated circuit chip is as important as 
designing it. If the designed chip is to be used in systems, 
it is essential to verify that it performs the intended 
function. This aspect must always be kept in mind during the 
design phase. 

There have been a great number of studies on testing. In 
this thesis these methods were examined with consideration 
given to a university environment. It has been decided that 
a functional test strategy is the appropriate approach in an 
academic environment. The use of Esim files, which are 
generated during the design phase, as test and reference 
data vectors is recommended. 

However, understanding other current methods is still 
necessary. For example,. student designers should study 
Design For Testability methods and use them wherever appro- 
priate. These methods not only reduce the effort of test 
generation and make automatic test generation possible, but 
also increase the observability and controllability of the 
chip. The LSSD ( Level Sensitive Scan Design) method fits 
well with a two-phase clocking scheme and provides access to 
signals that normally are not visible without using a large 
number of extra pins. 

After stating basic characteristics of a functional 
tester, two approaches were examined for designing a func- 
tional test system. It was observed in the first approach 
that controlling the complete test by a microprocessor is 
not fast enough. The second approach is faster and more 
reliable. Under the guidelines of this investigation, a test 
system architecture was proposed. Its 10 Mhz test speed, 1 
Mbyte memory depth, 10 nanosecond clock generation accuracy 
and 128 test pins provide a feasible tester. These 
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characteristics are adequate for our purposes, and allow, for 
example, a 16 bit LSI data path chip to be tested. 
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